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TECHNICAL FIELD 

The present invention generally relates to implantable cardiac therapy 
devices and ways to present information obtained from the implantable therapy 
devices. 

BACKGROUND 

Implantable cardiac therapy devices (ICTDs) are implanted within the body 
of a patient to monitor, regulate, and/or correct heart function. ICTDs include 
implantable cardiac stimulation devices (e.g., implantable cardiac pacemakers, 
implantable defibrillators) that apply stimulation therapy to the heart as well as 
implantable cardiac monitors that monitor heart activity. 

ICTDs typically include a control unit positioned within a casing that is 
implanted into the body and a set of leads that are positioned to impart stimulation 
and/or monitor cardiac activity. With improved processor and memory 
technologies, the control units have become increasingly more sophisticated, 
allowing them to monitor many types of conditions and apply tailored stimulation 
therapies in response to those conditions. 

ICTDs are typically capable of being programmed remotely by an external 
programming device, often called a "programmer". Today, individual ICTDs are 
equipped with telemetry circuits that communicate with the programmer. One 
type of programmer utilizes an electromagnetic wand that is placed near the 
implanted cardiac device to communicate with the implanted device. When used 
in a sterile field, the wand may be enclosed in a sterile sheath. The wand contains 
a coil that forms a transformer coupling with the ICTD telemetry circuitry. The 
wand transmits low frequency signals by varying coil impedance. 
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Early telemetry systems were passive, meaning that the communication was 
unidirectional from the programmer to the implanted device. Passive telemetry 
allowed a treating physician to download instructions to the implanted device 
following implantation. Due to power and size constraints, early commercial 
versions of the implanted devices were incapable of transmitting information back 
to the programmer. 

As power capabilities improved, active telemetry became feasible, allowing 
synchronous bi-directional communication between the implanted device and the 
programmer. Active telemetry utilizes a half-duplex communication mode in 
which the programmer sends instructions in a predefined frame format and, 
following termination of this transmission, the implanted device returns data using 
the frame format. With active telemetry, the treating physician is able to not only 
program the implanted device, but also retrieve information from the implanted 
device to evaluate heart activity and device performance. The treating physician 
may periodically want to review device performance or heart activity data for 
predefined periods of time to ensure that the device is providing therapy in desired 
manner. Consequently, current generation implantable cardiac therapy devices 
incorporate memories, and the processors periodically sample and record various 
performance parameter measurements in the memories. 

Data pertaining to a patient's cardiac condition is gathered and stored by 
the programmer during programming sessions of the ICTDs. Analysis of the 
cardiac condition is performed locally by the programming software. 
Programmers offer comprehensive diagnostic capabilities, high-speed processing, 
and easy operation, thereby facilitating efficient programming and timely patient 
follow-up. 
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In addition to local analysis, TransTelephonic Monitoring (TTM) systems 
are employed to gather current cardiac data from patients who are remote from the 
healthcare provider. TTM systems are placed in patients' homes. They typically 
include a base unit that gathers information from the ICTD much like the 
programmer would. The base unit is connected to a telephone line so that data 
may be transmitted to the medical staff responsible for that patient. An example of 
an ICTD TTM system is a service from St. Jude Medical® and Raytel® Cardiac 
Services called "Housecall™ This service provides current programmed 
parameters and episode diagnostic information for a plurality of events including 
stored electrograms (EGMs). Real-time EGMs with annotated status information 
can also be transmitted. 

Using a telephone and a transmitter, the TTM system provides both the 
medical staff and the patient the convenience of instant analysis of therapy without 
having the patient leave the comfort of home. Typically, real-time measurements 
are transmitted in just minutes. Patients may be closely monitored, and the medical 
staff has more control of their patient's treatment, thus administering better patient 
management. 

One challenge that still persists, however, is how to efficiently and 
effectively present patient information and cardiac data to medical personnel and 
other knowledge workers who might have an interest in the device data. People 
utilize different types of computing devices to receive and view data, such as 
computers, portable computers, personal digital assistants, facsimile machines, and 
so on. These computing devices have different user interface capabilities and 
features. Accordingly, there is a need for a system that delivers the data to a wide 
variety of computing devices. 
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SUMMARY 

A cardiac therapy network architecture collects data output by one or more 
implantable cardiac therapy devices, processes that data, and distributes it to 
various knowledge workers. The cardiac therapy network implements a 
presentation architecture that formats and encodes the data using different formats 
and protocols to facilitate distribution to and presentation on various computing 
devices with different user interface capabilities. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagrammatic illustration of a cardiac therapy network 
architecture with an implantable cardiac therapy device (ICTD) connected to a 
network of computing systems used by various knowledge workers. 

Fig. 2 is a functional diagram illustrating information flow from the ICTD 
to the computing systems associated with the knowledge workers. 

Fig. 3 is a functional diagram illustrating how the various computing 
systems share pieces of information to improve care given to the patient. 

Fig. 4 is a functional diagram illustrating information flow from the 
computing systems back to the ICTD. 

Fig. 5 is a simplified illustration of an ICTD in electrical communication 
with a patient's heart for monitoring heart activity and/or delivering stimulation 
therapy. 

Fig. 6 is a functional block diagram of an exemplary implantable cardiac 
therapy device. 
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Fig. 7 is a functional block diagram of an exemplary computing device that 
may be used in the computing systems of the cardiac therapy network architecture, 

Fig. 8 illustrates a presentation architecture implemented by the network 
architecture to facilitate distribution and presentation of information from the 
ICTD to the knowledge workers. 

Fig. 9 is a functional block diagram of an exemplary presentation system to 
format and encode content for delivery to the knowledge workers. 

Fig. 10 is a flow diagram of a method for presenting content to the 
knowledge workers. 

In the description that follows, like numerals or reference designators are 
used to reference like parts or elements. 

DETAILED DESCRIPTION 

The following description sets forth a cardiac therapy network architecture in 
which data collected from an implantable cardiac therapy device is processed and 
distributed to various knowledge workers. It is anticipated that the knowledge 
workers will utilize different computing devices for receiving and viewing the 
data. These computing devices vary widely in terms of their user interface (UI) 
capabilities. Accordingly, the network architecture implements a presentation 
architecture that formats and distributes content to various computing devices with 
different user interface capabilities. 

Cardiac Therapy Network 

Fig. 1 shows an exemplary cardiac therapy network architecture 100 that 
includes an implantable cardiac therapy device (ICTD) 102 coupled to a network 
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of computing systems associated with various knowledge workers who have 
interest in cardiac therapy. The ICTD is illustrated as being implanted in a human 
patient 104. The ICTD 102 is in electrical communication with a patient's heart 
106 by way of multiple leads 108 suitable for monitoring cardiac activity and/or 
delivering multi-chamber stimulation and shock therapy. 

The ICTD 102 may communicate with a standalone or offline programmer 
110 via short-range telemetry technology. The offline programmer 110 is 
equipped with a wand that, when positioned proximal to the ICTD 102, 
communicates with the ICTD 102 through a magnetic coupling. 

The ICTD 102 can alternatively, or additionally, communicate with a local 
transceiver 112. The local transceiver 112 may be a device that resides on or near 
the patient, such as an electronic communications device that is worn by the 
patient or is situated on a structure within the room or residence of the patient. 
The local transceiver 112 communicates with the ICTD 102 using short-range 
telemetry or longer-range high-frequency-based telemetry, such as RF (radio 
frequency) transmissions. Alternatively, the local transceiver 112 may be 
incorporated into the ICTD 102, as represented by dashed line 111. In this case, 
the ICTD includes a separate and isolated package area that accommodates high- 
frequency transmissions without disrupting operation of the monitoring and 
stimulation circuitry. 

Depending upon the implementation and transmission range, the local 
transceiver 112 can be in communication with various other devices of the 
network architecture 100. One possible implementation is for the local transceiver 
112 to transmit information received from the ICTD 102 to a networked 
programmer 114, which is connected to network 120. The networked programmer 
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114 is similar in operation to standalone programmer 110, but differs in that it is 

2 connected to the network 120. The networked programmer 1 14 may be local to, or 

3 remote from, the local transceiver 112; or alternatively, the local transceiver 112 

4 may be incorporated into the networked programmer 114, as represented by 
dashed line 116. 

Another possible implementation is for the local transceiver to be 
connected directly to the network 120 for communication with remote computing 
devices and/or programmers. Still another possibility is for the local transceiver 
112 to communicate with the network 120 via wireless communication, such as 
via a satellite system 122. 

The network 120 may be implemented by one or more different types of 
networks (e.g., Internet, local area network, wide area network, telephone, cable, 
satellite, etc.), including wire-based technologies (e.g., telephone line, cable, fiber 
optics, etc.) and/or wireless technologies (e.g., RF, cellular, microwave, IR, 
wireless personal area network, etc.). The network 120 can be configured to 
i6 support any number of different protocols, including HTTP (HyperText Transport 
= n Protocol), TCP/IP (Transmission Control Protocol/Internet Protocol), WAP 
i g (Wireless Application Protocol), Bluetooth, and so on. 

19 A number of knowledge workers are interested in data gathered from the 

20 implantable cardiac therapy device 102. Representative knowledge workers 

21 include healthcare providers 130, the device manufacturer 132, clinical groups 

22 134, and regulatory agencies 136. The knowledge workers are interested in 
different portions of the data. For instance, the healthcare providers 130 are 
interested in information pertaining to a particular patient's condition. The 

25 manufacturer 132 cares about how the device is operating. The clinical groups 



Ml 

ii% l^ 

Til 



14 



15 



SJ1-040US/A01E1049 
!ee@hayes pNc 509-324-9256 



1 10901 1039 SJ 1 -040 US. PAT. APP DOC 

SiJude Medical 



134 want certain data for inclusion in patient populations that can be studied and 
analyzed. The regulatory agencies 136 are concerned whether the devices, and 
various treatments administered by them, are safe or pose a health risk. 

The network architecture 100 facilitates distribution of the device data to 
the various knowledge workers. Information gathered from the device is 
integrated, processed, and distributed to the knowledge workers. Computer 
systems maintain and store the device data, and prepare the data for efficient 
presentation to the knowledge workers. The computer systems are represented 
pictorially in Fig. 1 as databases. However, such system can be implemented 
using a wide variety of computing devices, ranging from small handheld 
computers or portable digital assistants (PDAs) carried by physicians to 
workstations or mainframe computers with large storage capabilities. The 
healthcare providers 130 are equipped with computer systems 140 that store and 
process patient records 142. The manufacturer 132 has a computer system 144 
that tracks device data 146 returned from ICTDs 102. The clinical groups 134 
have computer systems 148 that store and analyze data across patient populations, 
as represented by a histogram 150. The regulatory agencies 136 maintain 
computer systems 152 that register and track healthcare risk data 154 for ICTDs. 

The network architecture 100 supports two-way communication. Not only 
is data collected from the ICTD 102 and distributed to the various computer 
systems of the knowledge workers, but also information can be returned from 
these computer systems to the networked programmer 114 and/or the local 
transceiver 112 for communication back to the ICTD 102. Information returned to 
the ICTD 102 may be used to adjust operation of the device, or modify therapies 



SJ1-040US/A01E1049 
lee@hayes pile 509.324-9266 



11 0901 1039 SJ 1 -040US.PAT.APP. DOC 

SxIudeMedkal 



9 



8 
9 
10 
11 



5 12 



ml 

• I* -13 



I 16 

18 
19 

20 
21 
22 
23 
24 
25 



being applied by the device. Such information may be imparted to the ICTD 102 
automatically, without the patient's knowledge. 

Additionally, information may be sent to a patient notification device 160 to 
notify the patient of some event or item. The patient notification device 160 can 
be implemented in a number of ways including, for example, as a telephone, a 
cellular phone, a pager, a PDA (personal digital assistant), a dedicated patient 
communication device, a computer, an alarm, and so on. Notifications may be as 
simple as an instruction to sound an alarm to inform the patient to call into the 
healthcare providers, or as complex as HTML-based pages with graphics and 
textual data to educate the patient. Notification messages sent to the patient 
notification device 160 can contain essentially any type of information related to 
cardiac medicinal purposes or device operation. Such information might include 
new studies released by clinical groups pertaining to device operation and patient 
activity (e.g., habits, diets, exercise, etc.), recall notices or operational data from 
the manufacturer, patient-specific instructions sent by the healthcare providers, or 
warnings published by regulatory groups. 

Notifications can be sent directly from the knowledge worker to the patient. 
Additionally, the network architecture 100 may include a notification system 170 
that operates computer systems 172 designed to create and deliver notification 
messages 174 on behalf of the knowledge workers. The notification system 170 
delivers the messages in formats supported by the various types of patient 
notification devices 160. For instance, if the patient carries a pager, a notification 
message might consist of a simple text statement in a pager protocol. For a more 
sophisticated wireless-enabled PDA or Internet-oriented cellular phone, messages 
might contain more than text data and be formatted using WAP formats. 
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1 Fig. 2 shows the flow of data from the implantable cardiac therapy device 

2 102 to the various computer systems used by the knowledge workers. Data from 

3 the ICTD is output as digital data, as represented by the string of 0 ? s and l's. The 

4 data may consist of any number of items, including heart activity (e.g., IEGM), 
s patient information, device operation, analysis results from on-device diagnostics, 

6 and so on. 

7 A data integrator 200 accumulates the data and stores it in a repository 202. 

8 A processing system 204 processes portions of the data according to various 

9 applications 206 that are specifically tailored to place the data into condition for 

10 various knowledge workers. For example, healthcare workers might be interested 
in certain portions of the data, such as the IEGM data and the patient information. 

|| 12 Clinical scientists might be interested in the heart data, but do not wish to see any 

Jj 13 patient information. Manufacturers may be interested in the raw data stream itself 

Hi 

g * 14 as a tool to discern how the device is operating. Depending on the needs of the 

is end worker, the processing system 204 takes the raw device data, evaluates its 

i6 accuracy and completeness, and generates different packages of data for delivery 

0 

hk n to the various knowledge workers. The processed data packages are also stored in 

is the repository 202. 

19 When the data is ready for delivery, a distribution/presentation system 208 

20 distributes the different packages to the appropriate computer systems 140, 144, 

21 148, 152, and 172. The distribution/presentation system 208 is configured to serve 

22 the packages according to the protocols and formats desired by the computer 

23 systems. In this manner, the network architecture 100 allows relevant portions of 

24 device data, collected from the ICTD, to be disseminated to the appropriate 

25 knowledge workers in a form they prefer. 
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Once the ICTD data is delivered, the computer systems 140, 144 5 148, 152, 
and 172 store the data and/or present the data to the knowledge worker. The 
computer systems may perform further processing specific to their use of the data. 
Through these processes, the knowledge workers create additional information 
that is useful to the patient, or other knowledge workers with interests in ICTDs. 
For example, from the ICTD data, the knowledge workers might devise improved 
therapies for a given patient, or create instructions to modify operation of a 
specific ICTD, or gain a better understanding of how implantable cardiac devices 
operate in general, or develop better technologies for future generations of ICTDs. 
Much of this created knowledge can be shared among the various knowledge 
workers. 

Fig. 3 shows how the various computing systems 140, 144, 148, 152, and 
172 can cooperate and share pieces of information to improve the care given to a 
patient. Where appropriate and legally acceptable, the computer systems may be 
configured to pass non-private information among the various knowledge workers 
to better improve their understanding of the implantable medical field. Clinical 
results 150 produced by the clinical computer systems 148 may be shared with 
healthcare providers to improve patient care or with manufacturers to help in their 
design of next generation devices. The sharing of information may further lead to 
better and timelier healthcare for the patients. 

If the collective knowledge base produces information that may prove 
helpful to the patient, that information can be passed to the notification system 172 
for delivery to one or more patients. Also, any one of the knowledge workers may 
wish to employ the notification system 172 to send messages to the patient(s). 
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Fig. 4 shows, in more detail, the flow of information back from the various 
computer systems used by the knowledge workers to the implantable cardiac 
therapy device 102 or the patient notification device 160. Information from any 
one of the computing systems — healthcare computer system(s) 140, manufacturer 
computer system(s) 144, clinical computer system(s) 148, regulatory computer 
system(s) 152 — or the notification system 172 can be sent to a patient feedback 
system 400. The patient feedback system 400 facilitates delivery of the 
information back to the patient. It may be an independent system, or incorporated 
into one or more of the computing. It may alternatively be integrated into the 
notification system 172. 

The patient feedback system 400 may be implemented in many ways. As 
one exemplary implementation, the patient feedback system 400 is implemented 
as a server that serves content back to the networked programmer 114, which then 
uses the information to program the ICTD 102 through a built in transceiver 116, 
local transceiver 112, or wand-based telemetry. As another possible 
implementation, the patient feedback system may be a cellular or RF transmission 
system that sends information back to the patient feedback device 160. 

The network architecture 100 facilitates continuous care around the clock, 
regardless of where the patient is located. For instance, suppose the patient is 
driving in the car when a cardiac episode occurs. The ICTD 102 detects the 
condition and transmits an alert message about the condition to the local 
transceiver 112. The message is processed and delivered to a physician's 
computer or PDA via the network 120. The physician can make a diagnosis and 
send some instructions back to the patient's ICTD. The physician might also have 
a notification message that guides the patient to a nearest healthcare facility for 
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further treatment sent via the notification system 170 to the patient's notification 

2 device 160. Concurrently, the physician can share the patient's records online with 

3 an attending physician at the healthcare facility so that the attending physician can 

4 review the records prior to the patient's arrival. 

Exemplary ICTD 

Fig. 5 shows an exemplary ICTD 102 in electrical communication with a 

8 patient's heart 106 for monitoring heart activity and/or delivering stimulation 

9 therapy, such as pacing or defibrillation therapies. The ICTD 102 is in electrical 

10 communication with a patient's heart 106 by way of three leads 108(l)-(3). To 



I:, 



ii sense atrial cardiac signals and to provide right atrial chamber stimulation therapy, 



|j i2 the ICTD 102 is coupled to an implantable right atrial lead 108(1) having at least 



V I 



« -> 15 



% 13 an atrial tip electrode 502, which typically is implanted in the patient's right atrial 

pj 

14 appendage. To sense left atrial and ventricular cardiac signals and to provide left 
chamber pacing therapy, the ICTD 102 is coupled to a coronary sinus lead 108(2) 

16 designed for placement in the coronary sinus region via the coronary sinus. The 

U n coronary sinus lead 108(2) positions a distal electrode adjacent to the left ventricle 

is and/or additional electrode(s) adjacent to the left atrium. An exemplary coronary 

19 sinus lead 108(2) is designed to receive atrial and ventricular cardiac signals and 

20 to deliver left ventricular pacing therapy using at least a left ventricular tip 

21 electrode 504, left atrial pacing therapy using at least a left atrial ring electrode 

22 506, and shocking therapy using at least a left atrial coil electrode 508. 

23 The ICTD 102 is also shown in electrical communication with the patient's 

24 heart 106 by way of an implantable right ventricular lead 108(3) having, in this 

25 implementation, a right ventricular tip electrode 510, a right ventricular ring 
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electrode 512, a right ventricular (RV) coil electrode 514, and an SVC coil 
electrode 516. Typically, the right ventricular lead 108(3) is transvenously 
inserted into the heart 102 to place the right ventricular tip electrode 510 in the 
right ventricular apex so that the RV coil electrode 514 will be positioned in the 
right ventricle and the SVC coil electrode 516 will be positioned in the superior 
vena cava. Accordingly, the right ventricular lead 108(3) is capable of receiving 
cardiac signals, and delivering stimulation in the form of pacing and shock therapy 
to the right ventricle. 

Fig. 6 shows an exemplary, simplified block diagram depicting various 
components of the IC1D 102. The ICTD 102 can be configured to perform one or 
more of a variety of functions including, for example, monitoring heart activity, 
monitoring patient activity, and treating fast and slow arrhythmias with stimulation 
therapy that includes cardioversion, defibrillation, and pacing stimulation. While a 
particular multi-chamber device is shown, it is to be appreciated and understood 
that this is done for illustration purposes. 

The circuitry is housed in housing 600, which is often referred to as the 
"can", "case", "encasing", or "case electrode", and may be programmably selected 
to act as the return electrode for unipolar modes. Housing 600 may further be 
used as a return electrode alone or in combination with one or more of the coil 
electrodes for shocking purposes. Housing 600 further includes a connector (not 
shown) having a plurality of terminals 602, 604, 606, 608, 612, 614, 616, and 618 
(shown schematically and, for convenience, the names of the electrodes to which 
they are connected are shown next to the terminals). 

To achieve right atrial sensing and pacing, the connector includes at least a 
right atrial tip terminal (A R TIP) 602 adapted for connection to the atrial tip 
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electrode 502. To achieve left chamber sensing, pacing, and shocking, the 
connector includes at least a left ventricular tip terminal (V L TIP) 604, a left atrial 
ring terminal (A L RING) 606, and a left atrial shocking terminal (A L COIL) 608, 
which are adapted for connection to the left ventricular ring electrode 504, the left 
atrial ring electrode 506, and the left atrial coil electrode 508, respectively. To 
support right chamber sensing, pacing, and shocking, the connector includes a 
right ventricular tip terminal (V R TIP) 612, a right ventricular ring terminal (V R 

8 RING) 614, a right ventricular shocking terminal (RV COIL) 616, and an SVC 

9 shocking terminal (SVC COIL) 618, which are adapted for connection to the right 
ventricular tip electrode 510, right ventricular ring electrode 512, the RV coil 
electrode 514, and the SVC coil electrode 516, respectively. 

At the core of the ICTD 102 is a programmable microcontroller 620 that 
n controls various operations of the ICTD, including cardiac monitoring and 

ftf 

H stimulation therapy. Microcontroller 620 includes a microprocessor (or equivalent 

ik is control circuitry), RAM and/or ROM memory, logic and timing circuitry, state 

Pi 

$ i6 machine circuitry, and I/O circuitry. Microcontroller 620 includes the ability to 

hk n process or monitor input signals (data) as controlled by a program code stored in a 

is designated block of memory. Any suitable microcontroller 620 may be used. The 

19 use of microprocessor-based control circuits for performing timing and data 

20 analysis functions are well known in the art. 

21 For discussion purposes, microcontroller 620 is illustrated as including 

22 timing control circuitry 632 to control the timing of the stimulation pulses (e.g., 

23 pacing rate, atrio-ventricular (AV) delay, atrial interconduction (A-A) delay, or 

24 ventricular interconduction (V-V) delay, etc.) as well as to keep track of the timing 

25 of refractory periods, blanking intervals, noise detection windows, evoked 
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response windows, alert intervals, marker channel timing, and so on. 
Microcontroller 220 may further include various types of cardiac condition 
detectors 634 (e.g., an arrhythmia detector, a morphology detector, etc.) and 
various types of compensators 636 (e.g., orthostatic compensator, syncope 
response module, etc.). These components can be utilized by the device 102 for 
determining desirable times to administer various therapies. The components 632- 
636 may be implemented in hardware as part of the microcontroller 620, or as 
software/firmware instructions programmed into the device and executed on the 
microcontroller 620 during certain modes of operation. 

The ICTD 102 further includes an atrial pulse generator 622 and a 
ventricular pulse generator 624 that generate pacing stimulation pulses for delivery 
by the right atrial lead 108(1), the coronary sinus lead 108(2), and/or the right 
ventricular lead 108(3) via an electrode configuration switch 626. It is understood 
that in order to provide stimulation therapy in each of the four chambers of the 
heart, the atrial and ventricular pulse generators, 622 and 624, may include 
dedicated, independent pulse generators, multiplexed pulse generators, or shared 
pulse generators. The pulse generators 622 and 624 are controlled by the 
microcontroller 620 via appropriate control signals 628 and 630, respectively, to 
trigger or inhibit the stimulation pulses. 

The electronic configuration switch 626 includes a plurality of switches for 
connecting the desired electrodes to the appropriate I/O circuits, thereby providing 
complete electrode programmability. Accordingly, switch 626, in response to a 
control signal 642 from the microcontroller 620, determines the polarity of the 
stimulation pulses (e.g., unipolar, bipolar, combipolar, etc.) by selectively closing 
the appropriate combination of switches (not shown). 

16 
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1 Atrial sensing circuits 644 and ventricular sensing circuits 646 may also be 

2 selectively coupled to the right atrial lead 108(1), coronary sinus lead 108(2), and 

3 the right ventricular lead 108(3), through the switch 626 to detect the presence of 

4 cardiac activity in each of the four chambers of the heart. Accordingly, the atrial 

5 (ATR. SENSE) and ventricular (VTR. SENSE) sensing circuits, 644 and 646, may 

6 include dedicated sense amplifiers, multiplexed amplifiers, or shared amplifiers. 

7 Each sensing circuit 644 and 646 may further employ one or more low power, 

8 precision amplifiers with programmable gain and/or automatic gain control, 

9 bandpass filtering, and a threshold detection circuit to selectively sense the cardiac 
y: io signal of interest. The automatic gain control enables the ICTD 102 to deal 
|J a effectively with the difficult problem of sensing the low amplitude signal 

m 12 characteristics of atrial or ventricular fibrillation. Switch 626 determines the 

-HI 

Jg B "sensing polarity" of the cardiac signal by selectively closing the appropriate 

W 

, 14 switches. In this way, the clinician may program the sensing polarity independent 

hk 15 of the stimulation polarity. 

" r. 

yj} 16 The outputs of the atrial and ventricular sensing circuits 644 and 646 are 

O 

U n connected to the microcontroller 620 which, in turn, is able to trigger or inhibit the 

is atrial and ventricular pulse generators 622 and 624, respectively, in a demand 

19 fashion in response to the absence or presence of cardiac activity in the 

20 appropriate chambers of the heart. The sensing circuits 644 and 646 receive 

21 control signals over signal lines 648 and 650 from the microcontroller 620 for 

22 purposes of controlling the gain, threshold, polarization charge removal circuitry 

23 (not shown), and the timing of any blocking circuitry (not shown) coupled to the 

24 inputs of the sensing circuits 644 and 646. 
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Cardiac signals are also applied to inputs of an analog-to-digital (A/D) data 
acquisition system 652. The data acquisition system 652 is configured to acquire 
intracardiac electrogram signals, convert the raw analog data into a digital signal, 
and store the digital signals for later processing and/or telemetric transmission to 
an external device 654. The data acquisition system 652 is coupled to the right 
atrial lead 108(1), the coronary sinus lead 108(2), and the right ventricular lead 
108(3) through the switch 626 to sample cardiac signals across any pair of desired 
electrodes. 

The data acquisition system 652 may be coupled to the microcontroller 620, 
or other detection circuitry, to detect an evoked response from the heart 106 in 
response to an applied stimulus, thereby aiding in the detection of "capture". 
Capture occurs when an electrical stimulus applied to the heart is of sufficient 
energy to depolarize the cardiac tissue, thereby causing the heart muscle to 
contract. The microcontroller 620 detects a depolarization signal during a window 
following a stimulation pulse, the presence of which indicates that capture has 
occurred. The microcontroller 620 enables capture detection by triggering the 
ventricular pulse generator 624 to generate a stimulation pulse, starting a capture 
detection window using the timing control circuitry 632 within the microcontroller 
620, and enabling the data acquisition system 652 via control signal 656 to sample 
the cardiac signal that falls in the capture detection window and, based on the 
amplitude, determines if capture has occurred. 

The microcontroller 620 is further coupled to a memory 660 by a suitable 
data/address bus 662, wherein the programmable operating parameters used by the 
microcontroller 620 are stored and modified, as required, in order to customize the 
operation of the implantable device 102 to suit the needs of a particular patient. 
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Such operating parameters define, for example, pacing pulse amplitude, pulse 
duration, electrode polarity, rate, sensitivity, automatic features, arrhythmia 
detection criteria, and the amplitude, waveshape and vector of each shocking pulse 
to be delivered to the patient's heart 106 within each respective tier of therapy. 
With memory 660, the ICTD 102 is able to sense and store a relatively large 
amount of data (e.g., from the data acquisition system 652), which may 
transmitted to the external network of knowledge workers for subsequent analysis. 

Operating parameters of the ICTD 102 may be non-invasively programmed 
into the memory 660 through a telemetry circuit 664 in telemetric communication 
with an external device, such as a programmer 110 or local transceiver 112. The 
telemetry circuit 664 advantageously allows intracardiac electrograms and status 
information relating to the operation of the device 102 (as contained in the 
microcontroller 620 or memory 660) to be sent to the external devices. 

The ICTD 102 can further include one or more physiologic sensors 670, 
commonly referred to as "rate-responsive" sensors because they are typically used 
to adjust pacing stimulation rate according to the exercise state of the patient. 
However, the physiological sensor 670 may further be used to detect changes in 
cardiac output, changes in the physiological condition of the heart, or diurnal 
changes in activity (e.g., detecting sleep and wake states, detecting position or 
postural changes, etc.). Accordingly, the microcontroller 620 responds by 
adjusting the various pacing parameters (such as rate, AV Delay, V-V Delay, etc.) 
at which the atrial and ventricular pulse generators, 622 and 624, generate 
stimulation pulses. While shown as being included within the device 102, it is to 
be understood that the physiologic sensor 670 may also be external to the device 
102, yet still be implanted within or carried by the patient. Examples of 
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1 physiologic sensors that may be implemented in device 102 include known 

2 sensors that, for example, sense respiration rate and/or minute ventilation, pH of 

3 blood, ventricular gradient, and so forth. 

4 The ICTD 102 additionally includes a battery 676 that provides operating 

5 power to all of circuits shown in Fig. 2. If the device 102 is configured to deliver 

6 pacing or shocking therapy, the battery 676 is capable of operating at low current 

7 drains for long periods of time (e.g., preferably less than 10 jjA), and is capable of 
s providing high-current pulses (for capacitor charging) when the patient requires a 

9 shock pulse (e.g., preferably, in excess of 2 A, at voltages above 2 V, for periods of 

10 10 seconds or more). The battery 676 also desirably has a predictable discharge 
characteristic so that elective replacement time can be detected. As one example, 

S| 12 the device 102 employs lithium/silver vanadium oxide batteries. 

JJ 13 The ICTD 102 can further include magnet detection circuitry (not shown), 

14 coupled to the microcontroller 620, to detect when a magnet is placed over the 

jl 15 device 102. A magnet may be used by a clinician to perform various test functions 

5j i6 of the device 102 and/or to signal the microcontroller 620 that the external 

p- n programmer is in place to receive or transmit data to the microcontroller 620 

is through the telemetry circuits 664. 

19 The ICTD 102 further includes an impedance measuring circuit 678 that is 

20 enabled by the microcontroller 620 via a control signal 680. Uses for an 

21 impedance measuring circuit 678 include, but are not limited to, lead impedance 

22 surveillance during the acute and chronic phases for proper lead positioning or 

23 dislodgement; detecting operable electrodes and automatically switching to an 

24 operable pair if dislodgement occurs; measuring respiration or minute ventilation; 

25 measuring thoracic impedance for determining shock thresholds; detecting when 
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the device has been implanted; measuring stroke volume; and detecting the 
opening of heart valves, etc. The impedance measuring circuit 678 is 
advantageously coupled to the switch 626 so that any desired electrode may be 
used. 

In the case where the device 102 is intended to operate as an implantable 
cardioverter/defibrillator (ICD) device, it detects the occurrence of an arrhythmia, 
and automatically applies an appropriate electrical shock therapy to the heart 
aimed at terminating the detected arrhythmia. To this end, the microcontroller 620 
further controls a shocking circuit 682 by way of a control signal 684. The 
shocking circuit 682 generates shocking pulses of low (up to 0.5 Joules), moderate 
(0.5 - 10 Joules), or high energy (11 to 40 Joules), as controlled by the 
microcontroller 620. Such shocking pulses are applied to the patient's heart 106 
through at least two shocking electrodes, and as shown in this implementation, 
selected from the left atrial coil electrode 508, the RV coil electrode 514, and/or 
the SVC coil electrode 516. As noted above, the housing 600 may act as an active 
electrode in combination with the RV coil electrode 514, or as part of a split 
electrical vector using the SVC coil electrode 516 or the left atrial coil electrode 
508 (i.e., using the RV electrode as a common electrode). 

Cardioversion shocks are generally considered to be of low to moderate 
energy level (so as to minimize pain felt by the patient), and/or synchronized with 
an R-wave and/or pertaining to the treatment of tachycardia. Defibrillation shocks 
are generally of moderate to high energy level (i.e., corresponding to thresholds in 
the range of 5-40 Joules), delivered asynchronously (since R-waves may be too 
disorganized), and pertaining exclusively to the treatment of fibrillation. 
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Accordingly, the microcontroller 620 is capable of controlling the synchronous or 
asynchronous delivery of the shocking pulses. 

The ICTD 102 may further be designed with the ability to support high- 
frequency wireless communication, typically in the radio frequency (RF) range. 
As illustrated in Fig. 2, the can 600 may be configured with a secondary, isolated 
casing 690 that contains circuitry for handling high-frequency signals. Within this 
separate case 690 are a high-frequency transceiver 692 and a diplexer 694. High- 
frequency signals received by a dedicated antenna, or via leads 108, are passed to 
the transceiver 692. Due to the separate casing region 690, the transceiver handles 
the high-frequency signals in isolation apart from the cardiac therapy circuitry. In 
this manner, the high-frequency signals can be safely handled, thereby improving 
telemetry communication, without adversely disrupting operation of the other 
device circuitry. 

Exemplary Computing Device 

Fig. 7 shows an exemplary computing device 700 employed in the 
computing systems of the cardiac therapy network architecture 100. It includes a 
processing unit 702 and memory 704. Memory 704 includes both volatile 
memory 706 (e.g., RAM) and non-volatile memory 708 (e.g., ROM, EEPROM, 
Flash, disk, optical discs, persistent storage, etc.). An operating system and 
various application programs 710 are stored in non-volatile memory 708. When a 
program is running, various instructions are loaded into volatile memory 706 and 
executed by processing unit 702. Examples of possible applications that may be 
stored and executed on the computing device include the knowledge worker 
specific applications 206 shown in Fig. 2. 
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The computing device 700 may further be equipped with a network I/O 
connection 720 to facilitate communication with a network. The network I/O 720 
may be a wire-based connection (e.g., network card, modem, etc.) or a wireless 
connection (e.g., RF transceiver, Bluetooth device, etc.). The computing device 
700 may also include a user input device 722 (e.g., keyboard, mouse, stylus, touch 
pad, touch screen, voice recognition system, etc.) and an output device 724 (e.g., 
monitor, LCD, speaker, printer, etc.). 

Various aspects of the methods and systems described throughout this 
disclosure may be implemented in computer software or firmware as computer- 
executable instructions. When executed, these instructions direct the computing 
device (alone, or in concert with other computing devices of the system) to 
perform various functions and tasks that enable the cardiac therapy network 
architecture 100. 

Presentation Architecture 

One feature of the network architecture is a presentation architecture that 
enables presentation of data obtained from the implantable cardiac therapy device 
to various knowledge workers. The presentation architecture places the data in a 
suitable format and protocol to accommodate different types of computing devices 
with different UI capabilities. The presentation architecture separates the 
processing and presentation functions so that decisions regarding how to present 
the content are made independently of the collection and processing of the data. 

Fig. 8 shows the presentation architecture 800 that is implemented by the 
network architecture. The presentation architecture 800 has three layers: an 
information source layer 802, a processing layer 804, and a presentation layer 806. 
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The information source layer 802 provides the data or information that is to be 
processed and presented to the knowledge worker. This layer includes data output 
by the ICTD, such as heart activity (e.g., IEGM), patient information, device 
operation data, analysis results from on-device diagnostics, and so on. It may 
further include other information made available for purposes of processing or 
better understanding the ICTD data. 

The processing layer 804 performs the data handling and analytical 
processes. This layer contains the applications and methods that conform the data 
into content that will ultimately be presented to the knowledge workers. The 
processing layer 804 may include, for example, the processing system 204 and 
applications 206 that create the content desired by the knowledge workers. 

The presentation layer 806 is responsible for getting the content to the 
knowledge worker in a form they prefer. This layer 806 contains the applications 
and processes that determine which content to present to whom, the format of the 
content, and the protocol by which to send the content. 

Fig. 9 shows one exemplary implementation of the presentation layer 806 
configured as the distribution/presentation system 208. The presentation layer 806 
enables effective delivery and presentation of content to many different types of 
computing devices, as represented by exemplary devices 900(l)-(8). It is 
anticipated that knowledge workers will utilize many diverse types of computing 
devices, including pagers 900(1), personal digital assistants (PDAs) 900(2), Web- 
enabled or "smart" phones 900(3), portable computers 900(4), facsimile machines 
900(5), cellular phones 900(6), databases 900(7), and desktop computers 900(8). 
These devices may be implemented using open standard software and protocols, or 
proprietary software and protocols. 



SJ1-040US/A01E1049 
Iee@hayes piic 509-324-9256 



24 



1109011039 SJ1-040US.PATAPP.DOC 

StJudeMewcal 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



The presentation layer 806 includes a content component store 902 to store 
snippets of content ready to be presented to the knowledge worker. The content 
may include raw data, processed data, additional information added during 
processing, and so on. Although the content store 902 is illustrated in Fig. 9 as 
residing at the distribution/presentation system 208, it may also reside in the 
repository 202. 

The presentation layer 806 may further include a content selector 904 to 
choose the content components from store 902 for presentation to the various 
knowledge workers. For instance, the content selector 904 may select patient- 
related data (e.g., IEGM, therapy parameters, patient information, etc.) for 
presentation to healthcare workers. It might further choose device-related 
information (e.g., raw IEGM data) for presentation to the manufacturer. 

The content selector 904 maintains a set of knowledge worker records 906 
in a database or other storage unit. The knowledge worker records 906 specify the 
worker's contact information, information preferences, and computing resources. 
The records 906 track, for example, the worker's email address, phone numbers, 
and pager numbers. The records 906 might further specify the type of information 
desired by the knowledge worker and the type(s) of computing devices 900 that 
the knowledge worker uses. As one example, a record 906 for a cardiac physician 
may specify the contact information, the doctor's preference to see IEGM data 
output by the ICTD, and that the primary computing device is a Palm Pilot® PDA 
900(2) with wireless communication capabilities but limited UI features. 

A user interface (UI) specification store 910 maintains the rules that dictate 
how the content is to be presented on different computing devices and software 
platforms. The computing devices 900(l)-(7) have a wide variety of UI features 
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and capabilities, ranging from high-resolution color monitors, to single-line LCD 
displays or audio alarms, to database structures and facsimile machines. 

The UI specification store 910 maintains one or more UI definitions 912 
that specify device requirements for visual/audio output. The UI definitions 912 
include such parameters of whether devices have a display and if so, the display 
type (e.g., LCD, CRT, LED, etc.), display size, whether the display is capable of 
showing graphics and/or color, whether audio is possible, and so on. These UI 
definitions 912 help the content selector 904 identify which snippets of 
information in the content store 902 should be selected for a given device 
specified in the knowledge worker record 906. 

The UI specification store 910 also includes one or more style sheets 914 
that specify how the content is to be arranged for a given computing device. The 
style sheets 914 specify the format of the information, such as HTML, XML, 
SNMP (Simple Network Management Protocol), etc. The sheets also dictate the 
type of content that can be included, such as graphical components, text, audio, 
video, and so on. 

The presentation layer 806 might also include a content formatter 920 to 
place the content into the appropriate format specified by the UI specification store 
910 for a target computing device. For instance, if a particular knowledge worker 
utilizes a laptop computer that is capable of receiving HTML documents, the 
content formatter 920 formats the content in HTML for effective presentation. If 
another knowledge worker has a cellular phone, the content formatter 920 may 
format the content text that can be readily depicted on a limited display. 

A delivery protocol encoder 922 encodes the formatted content according to 
the protocols supported by the computing devices and networks used by the 
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knowledge worker. There are many possible protocols, including HTTP, TCP/IP, 
WAP, Bluetooth, etc. Depending upon the preferences specified in the knowledge 
worker records 906, the delivery protocol encoder 922 encodes the content to the 
appropriate delivery protocol for subsequent distribution to the devices operated 
by the knowledge workers. 

Separating the presentation and processing layers and implementing UI 
definitions and style sheets enables the architecture to distribute content produced 
by multiple applications to a wide assortment of computing devices without 
requiring unique UIs for each computing device. Suppose there are three 
applications that produce content to be distributed to four different computing 
devices of the knowledge workers. If the presentation layer were integrated with 
the processing layer, the application developer would need to write a specific UI 
for each device, resulting in twelve different versions of UI code (i.e., the number 
of applications times the number of devices). 

By separating the presentation layer, however, independent UI definitions 
912(l)-(3) can be developed to specify UI requirements imposed by individual 
applications. Style sheets 910(l)-(4) can be created to describe what features 
individual devices are able to support. Combining the UI definition with a style 
sheet dictates what content is presented and how it is presented for a given 
computing device. In this example, the architecture allows, at most, the creation 
of seven definitions/sheets to facilitate presentation of content from three 
applications on four devices (i.e., the number of applications plus the number of 
devices), down from twelve separate versions. 

This architecture is easily adopted to support new computing devices. A 
developer defines a new UI definition and/or a style sheet to enable presentation of 
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content on the new device. This saves time and money in that developers are not 
forced to modify applications as UT capabilities of the end-user computing devices 
change. 

Presentation Operation 

Fig. 10 shows a process 1000 for presenting content to the knowledge 
workers. Aspects of this process may be implemented in hardware, firmware, or 
software, or a combination thereof. 

At block 1002, the distribution/presentation system 208 determines what 
computing resources are available for the knowledge worker who is intended to 
receive the information. The system consults the knowledge worker records 906 
to identify the types of computing devices specified by the knowledge worker. At 
block 1004, the system ascertains the features and capabilities of the computing 
resources of the intended knowledge worker. Such features may include display 
type, display size, graphical capabilities, color capabilities, etc. 

At block 1006, the content selector 904 selects the content to be delivered 
to the knowledge worker based, in part, on the capabilities of the computing 
resources. For instance, if the knowledge worker is carrying a PDA or phone of 
limited screen size, the content selector 904 extracts summary statements or 
phrases from the content component store 902 that can be presented on the device. 
For instance, the content selector might choose a statement "IEGM for Patient X is 
ready for viewing". Such a message would inform the knowledge worker that 
pertinent patient data is ready for downloading next time the knowledge worker is 
at a device capable of viewing and analyzing IEGM charts. For devices of higher 
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capabilities (e.g., portable or desktop computer), the content selector may choose 
full data graphs and/or commentary to present to the knowledge worker. 

At block 1008, the content formatter 920 formats the selected content into 
suitable formats for presentation on the knowledge worker's computing device. 
Possible formats include HTML, XML, and SNMP. At block 1010, the delivery 
protocol encoder 922 encodes the content according to a protocol supported by the 
target network and computing device. Examples of possible protocols include 
HTTP, TCP/IP, WAP, Bluetooth, etc. At block 1012, the system 208 delivers the 
content to the knowledge worker's computing device, where it is presented for 
review and analysis by the knowledge worker. 

Conclusion 

Although the invention has been described in language specific to structural 
features and/or methodological acts, it is to be understood that the subject matter 
defined in the appended claims is not necessarily limited to the specific features or 
acts described. Rather, the specific features and acts are disclosed as exemplary 
forms of implementing the claimed invention. 
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